Method and system for locking resources in a distributed environment

ABSTRACT

A method and system that creates and maintains lock properties for a resource or object in a distributed environment. The lock properties provide other client computer systems limited availability to the locked resource. Limited availability relates to being able to only read, write or delete the resource, or any combination thereof. Additionally, these lock properties allow other client computer systems to simultaneously hold or share equivalent locks. Other lock properties relate to advisory or mandatory status for the lock. Advisory locks may be honored or ignored by other client computer systems.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of prior U.S. patent application Ser.No. 09/992,644, entitled “Method and System for Locking Resources in aDistributed Environment,” filed Nov. 13, 2001, which is herebyincorporated herein by reference in its entirety.

TECHNICAL FIELD

This invention relates generally to distributed computing environmentsand particularly to availability management of resources in adistributed environment. More particularly, the present inventionrelates to methods of “locking” distributed environment resources toprevent inappropriate access to such resources. More particularly still,the present invention relates to locking methods that extend the WebDAVprotocol.

BACKGROUND OF THE INVENTION

Distributed computer environments, such as computer networks, providesignificant advantages to multiple computer clients or users. Inparticular, distributed environments allow multiple clients to actuallyshare many different computer resources including both hardware andsoftware resources. Sharing software-related resources provides manyknown benefits, such as the fact that only one such resource needs to becreated, updated and maintained.

The Internet is one particular example of a distributed environment thatprovides access to a considerable number of software resources, whichare available to practically any client computer system having Internetcapabilities. One portion of the Internet is known as the World Wide Webwhich is a generally a system of Internet servers that house softwarerelated resources that are formatted in a particular manner, such aswith HTML (HyperText Markup Language). The protocol for accessing theseparticular resources is known as the HyperText Transfer Protocol orHTTP. It should be noted however that not all Internet servers are partof the World Wide Web.

Historically, most resources on the Internet corresponded to web pagefiles that included only static HTML code, and thus were only availablefor display. However, recent advances are being made in therepresentative functionality provided to client systems to provide moreinteraction between the client and server systems. For instance, clientsmay effectively author resources on a server system from client systemsover distributed networks, including the Internet. Indeed, much time andeffort has been spent on the development of a WebDAV protocol orstandard, which stands for the World Wide Web Distributed Authoring andVersioning standard, referred to herein as simply “DAV.” DAV provides aset of headers and methods which extend HTTP to provide capabilities formanaging properties, namespace and other items from a client system inorder to allow client computer systems to access server-side resourcesfor the purpose of editing those resources. Proposed Standard RFC 2518,which is a document written by the IETF and approved by the IESG,published February 1999, describes DAV in more detail.

As part of the DAV standard, server computer systems provide variousservices in managing the various access requests made by clients. Oneparticular service relates to controlling when a resource is availablefor use by a client. That is, DAV provides methods that allow a clientto lock a resource when using that resource so that subsequent users maynot access that resource during that time. This locking scheme helpsprevent the “lost update” problem associated with two or more usersmodifying a resource simultaneously such that editions are inadvertentlylost. Unfortunately however, the DAV protocol only provides two types oflocks, an exclusive write lock and a shared write lock.

Although the exclusive and shared write locks are helpful in preventingthe lost update problem, DAV does not support open sharing modes foundin existing platforms, such as the Win32® platform. For example, if aclient is not concerned with whether others edit or delete a resource itis using, but wants to prevent others from reading that resource whileit is being used, the Win32® platform supports such a lock, but there isno method to support this lock function in DAV. Similarly, if a userwants to prevent others from deleting a resource, but is not concernedwith whether others read a resource, the Win32® platform supports thisfunction but there is no method to support this function in DAV.

The inability to provide these types of sharing procedures raisessignificant compatibility issues since many existing applications, suchas word processing applications, utilize these open sharing modes.Consequently, when those applications are used over the Internet incombination with the DAV protocol, the open sharing modes are notsupported. Therefore, much of the functionality is not available and mayeven cause errors to occur when attempting to use these unsupportedmethods.

Another drawback associated with the limited locking scheme relates tothe fact that the locks are mandatory in the DAV protocol. That is, theDAV protocol cannot express advisory locks, which are well known in theUNIX platform. In the UNIX platform, cooperating applications can checkfor the presence of advisory locks that conflict with the attemptedoperation and honor that advisory lock, but there is no requirement tohonor the lock. An application is therefore allowed to access a resourceand edit that resource even when such access conflicts with an advisorylock. Although this scheme is prevalent in UNIX applications, there isno mechanism in DAV to create a lock that is advisory. Consequently,many Unix applications are incompatible with the DAV protocol.

It is with respect to these and other considerations that the presentinvention has been made.

SUMMARY OF THE INVENTION

The present invention solves these problems by creating and enabling theuse of new shared lock types relating to shared read locks, shared writelocks and shared delete locks. The method and system creates andmaintains lock properties for a resource or object in a distributedenvironment. The lock properties provide other client computer systemslimited availability to the locked resource. Limited availabilityrelates to being able to only read, write or delete the resource, or anycombination thereof. Additionally, these lock properties allow otherclient computer systems to simultaneously hold or share equivalentlocks. Other lock properties provided by the present invention relate toadvisory or mandatory status for the lock. Advisory locks may be eitherhonored or ignored by other client computer systems.

In accordance with certain aspects, the present invention relates to amethod of locking a resource wherein the method comprises the acts ofreceiving a request to access the resource, wherein the requestoriginates from a requesting client computer system; creating a lockhaving a predetermined type, wherein the predetermined type providesavailability to other client computer systems for predeterminedpurposes; providing a lock token related to the created lock to therequesting client computer system; and performing the requested access.

Additionally, the request to access the resource may provide anindication as to the type of access and to the type of lock to becreated during the access. In such a case, prior to the act of creatinga lock, the method may comprise the act of determining whether theresource is locked by another client computer system. Further the act ofcreating a lock only occurs if no existing lock conflicts with the typeof access requested or the type of lock requested. In accordance withother aspects, the predetermined type of the lock provides other clientcomputer systems access to the resource for the purpose of only reading,writing or deleting the resource or some combination thereof.

In accordance with other aspects, the lock may be advisory or mandatory.Mandatory locks may not be ignored such that conflicting access requestsare denied. On the other hand, advisory locks may be honored or ignored,as determined by the requesting client system.

The invention may be implemented as a computer process, a computingsystem or as an article of manufacture such as a computer programproduct. The computer program product may be a computer storage mediumreadable by a computer system and encoding a computer program ofinstructions for executing a computer process. The computer programproduct may also be a propagated signal on a carrier readable by acomputing system and encoding a computer program of instructions forexecuting a computer process.

A more complete appreciation of the present invention and itsimprovements can be obtained by reference to the accompanying drawings,which are briefly summarized below, to the following detail descriptionof presently preferred embodiments of the invention, and to the appendedclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a distributed environment having a clientcomputer system and a server computer system that communicate accordingto principles of the present invention.

FIG. 2 is a functional diagram of a computer system that may incorporateaspects of the present invention.

FIG. 3 is a block diagram illustrating software components of thepresent invention.

FIG. 4 is a flow diagram illustrating the functional components ofaccessing and locking a resource according to the present invention.

FIG. 5 is a flow diagram illustrating the functional components ofaccessing and locking a resource according to an alternative embodimentof the present invention.

DETAILED DESCRIPTION OF THE INVENTION

A distributed environment 10 incorporating aspects of the presentinvention is shown in FIG. 1. The environment 10 has at least one clientcomputer system, such as client computer systems 12, 14 and 16 thatinteract with at least one server computer system, such as servercomputer system 18 over a distributed network, such as the Internet 20.The client computer systems 12, 14 and 16 request access to one or moreserver computer resources 22. Additionally, there may be other clientcomputer systems as indicated by ellipses 24. The resources 22 relate tocomputer readable files or objects, such as text documents, applicationprogram modules, data objects, properties or attributes for dataobjects, among others. The resources may be HTML, XML, SGML files, or inother embodiments, the resources may be in another format.

In an embodiment of the invention, the protocol used by the systems 12,14, 16 and 18 to communicate is the WebDAV (World Wide Web DistributedAuthoring and Versioning, hereinafter “DAV”) protocol. DAV is anextension of the Hypertext Transfer Protocol version 1.1 (HTTP) andprovides the methods and formats for allowing client computer systems,such as computer systems 12, 14 and 16 to access and edit computerresources 22. As stated in the Background Section above, DAV alsoprovides a set of headers and methods, which extend the HTTP to providecapabilities for property and namespace management, among other featuresas discussed in Proposed Standard RFC 2518.

As one client computer system, such as system 12, accesses one of theresources 22, that resource may be locked such that the other clientcomputer systems, such as systems 14 and 16 are unable to access theresource for any purpose. In other embodiments, one or the othercomputer systems 14 and 16 may access the locked resource, but only forlimited purposes, such as to write to the resource, read the resource orto delete the resource depending on the type of lock used on theresource by the first client computer system. In yet another embodiment,the lock may be considered advisory, such that the other client computersystems 14 and 16 may decide whether to honor the lock or to ignore thelock and access the resource accordingly.

FIG. 2 illustrates an example of a suitable computing system environment100 in which aspects of the present invention may be implemented aseither a client computer system such as systems 12, 14 or 16 or servercomputer system 18. The computing system environment 100 is only oneexample of a suitable computing environment and is not intended tosuggest any limitation as to the scope of use or functionality of theinvention. Neither should the computing environment 100 be interpretedas having any dependency or requirement relating to any one orcombination of components illustrated in the exemplary operatingenvironment 100.

Environment 100 incorporates a general purpose computing device in theform of a computer 102. Components of computer 102 may include, but arenot limited to, a processing unit 104, a system memory 106, and a systembus 108 that couples various system components including the systemmemory to the processing unit 104. The system bus 108 may be any ofseveral types of bus structures including a memory bus or memorycontroller, a peripheral bus, and a local bus using any of a variety ofbus architectures. By way of example, and not limitation, sucharchitectures include Industry Standard Architecture (ISA) bus, MicroChannel Architectures (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus also known as Mezzanine bus.

Computer 102 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 102 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CDE-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 102. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 106 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 110and random access memory (RAM) 112. A basic input/output system 114(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 102, such as during start-up, istypically stored in ROM 110, while RAM 112 typically contains filesand/or program modules that are immediately accessible to and/orpresently being operated on by processing unit 104. By way of example,and not limitation, FIG. 2 illustrates operating system 132, applicationprograms 134, other program modules 136, and program data 138.Additionally, the computer 102 comprises a file system, which definesthe format for the files of system 102, and further definesversion-specific property formats, as discussed below.

The computer 102 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 2 illustrates a hard disk drive 116 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 118that reads from or writes to a removable, nonvolatile magnetic disk 120,and an optical disk drive 122 that reads from or writes to a removable,nonvolatile optical disk 124 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 116 is typically connectedto the system bus 108 through a non-removable memory interface such asinterface 126, and magnetic disk drive 118 and optical disk drive 122are typically connected to the system bus 108 by a memory interfaces,such as interfaces 128 and 130, respectively.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 2, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 102. In FIG. 2, for example, hard disk drive 116 is illustratedas storing operating system 132, application programs 134, other programmodules 136, and program data 138.

A user may enter commands and information into the computer 102 throughinput devices such as a keyboard 140 and pointing device 142, commonlyreferred to as a mouse, trackball or touch pad. Other input devices (notshown) may include a microphone, joystick, game pad, satellite dish,scanner, or the like. These and other input devices are often connectedto the processing unit 104 through an input interface 148 that iscoupled to the system bus 108. A monitor 150 or other type of displaydevice may also be connected to the system bus 108 via video adapter152. In addition to the monitor, computers may also include otherperipheral output devices such as speakers and printer not shown.

The computer 102 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer154. The remote computer 154 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 102.

When used in a LAN networking environment, the computer 102 is connectedto the LAN through a network interface or adapter 162. When used in aWAN networking environment, the computer 102 typically includes a modem164 or other means for establishing communications over the WAN, such asthe Internet. The modem 164, which may be internal or external, may beconnected to the system bus 108 via the user input interface 148, orother appropriate mechanism. In a networked environment, program modulesdepicted relative to the computer 102, or portions thereof, may bestored in the remote memory storage device. It will be appreciated thatthe network connections shown are exemplary and other means ofestablishing a communications link between the computers may be used.

In addition to the environment 100 shown in FIG. 2, the invention may beoperational with numerous other general purpose or special purposecomputing system environments or configurations. Examples of well knowncomputing systems, environments, and/or configurations that may besuitable for use with the invention include, but are not limited to,personal computers, server computers, hand-held or laptop devices,multiprocessor systems, microprocessor-based systems, set top boxes,programmable consumer electronics, network PCs, minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like.

Moreover, the present invention may be described in the general contextof a software operating environment, e.g., computer-executableinstructions, such as program modules, being executed by a computer.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. The invention may also bepracticed in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote computer storage mediaincluding memory storage devices.

FIG. 3 illustrates an example of a software operating environment 200 inwhich the invention may be implemented. The software operatingenvironment 200 is only one example of a suitable operating environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. Software environment 200 incorporates aServer System Resource Store 202 which defines the format and structureof data objects, such as data objects 204 and 206. Typically, the ServerSystem Resource Store 202 also provides the overall structure in whichobjects are named, stored and organized. Additionally, the storeprovides the protocols for accessing any object within the store 202. Inan embodiment, Store 202 is an XML store and has data objects defined bythe XML standard. However, it is contemplated that other data objectconfigurations or collections may incorporate the aspects of the presentinvention. Data objects 204 and 206 are data objects that representactual file-type data. The objects 204 and 206 may be accessed and/ormodified by a user or another program module. Of course, the Store 202may comprise many other objects as indicated by ellipses 212.

Typically, each data object 204 and 206 has some form of metainformation object (not shown) that is associated with each object, themeta information comprises information such as the author of the object,the time the object was last accessed, among others. This metainformation may be stored as part of the data object or as part ofanother object having a pointer or some other identifying element thatassociates the meta information object with its particular data object.

In addition to the meta information objects, a data object may also beassociated with a lock object, such as objects 208 and 210. Lock objects208 and 210 are associated with data objects 204 and 206, respectively.Lock objects comprise information related to whether its associated dataobject is locked and therefore inaccessible by other client computersystems. Additionally, lock objects 204 and 206 may provide otherfunctions, such as providing control over the types of locking methods,and/or the servicing of lock token requests. Although shown as separateobjects, lock objects 204 and 206 may be incorporated into the dataobject itself as part of a header or some other meta-information portionof the data object.

Environment 200 also has a services layer 214, which relates to serverfunctionality in servicing access requests for data objects 204 and 206.The services layer 214 may provide various functions, such as ensuringthat an object access request complies with the existing protocol;whether the request relates to either an existing object or, in DAV, toan object that is to be created; whether the module making the requesthas permission to make and perform the request; among others. Theservices layer 214 also manages the availability of resources based onlock analysis as discussed in more detail below.

The services layer 214 receives requests over a distributed networkenvironment, such as Internet 216. The requests are made by clientcomputer applications, such as applications 218 and 220. In oneembodiment, application program 218 is a client application program thatoperates on a client system apart from a server system, wherein theserver system is the physical location of the Store 202. In otherembodiments however, the application program, i.e., program 218 mayactually be part of the server system. Applications 218 and 220 interactwith the distributed network environment 216 through application programinterfaces 222 and 224, respectively. The access requests may involverequests to move, copy, delete, read, execute or update a resource orobject, such as object 204 or object 206.

With respect to the lock objects 208 and 210, in an embodiment of theinvention, application programs 218 and 220 may cause the creation oflock objects 208 and 210 related to objects 204 and 206 respectively.Alternatively, the services layer 214 may create the lock objects, andassociate the objects with the data objects. Once a lock object, e.g.,lock object 208, has been created, another application may determine theexistence of such a lock object and access the locked data object onlyin accordance with parameters set by the lock object, if at all.

In one particular example, the services layer 214 actually performs thecreation and management of the lock objects 208 and 210. As described inmore detail below, the services layer 214 receives a request from aclient application program, such as application 218. The services layerthen processes the request, i.e., determines whether the clientapplication may access the data object in the requested manner. If theapplication is able to access the data object in the requested manner,the services layer returns a lock token 226 to the client applicationprogram 218 and allows the requested access. If the services layer 214determines that the application program may not access the requesteddata object in the requested manner, such as to read, write, or deletethe resource, access is denied.

To further this example, assume application program 220 attempts toaccess a data object that is locked by client application 218, asevidenced by the lock token 226. In such a case the application 220cannot access that data object until client application 218 frees thelock token 226. However, as discussed in more detail below, depending onthe type of lock created by client application 218, client applicationprogram 220 may still be able to access the locked data object toperform predetermined operations, such as to only read the data object,or to only delete the data object, etc.

The types of locks provided by the services layer, and used by theclient application programs 218 and 220 may be either shared locks orexclusive locks. Exclusive locks do not allow any other clients or usersto access the locked application for any reason, while shared locksallow other clients to access the application for limited purpose. Ascontemplated by the present invention, at least three new types ofshared locks are added to the DAV protocol.

The first type of lock is referred to herein as a “write lock” wherein awrite lock prevents any accesses to a resource for writing to theresource or deleting the resource. Another lock type is referred toherein as a “nosharewrite lock” wherein a nosharewrite lock prevents anyaccesses to a resource for writing to the resource. However, anotherclient may still read the resource and delete the resource or propertiesof the resource.

Another type of lock, the “nosharedelete lock” allows other clients toread or write to an otherwise locked application, but does not allow anydelete operations. Yet another lock, the “noshareread lock” preventsothers from reading a resource.

In an embodiment of the invention, a “locktype” property is used,wherein the locktype property is an extension of the HTTP, as part ofDAV. In essence, the locktype property is a new type of DAV property andhas the same live/dead degree of freedom as other DAV properties, i.e.,where a live property is managed at a server and dead property ismanaged at the client. Additionally, the different locktype values ortypes include the write lock, the nosharewrite lock, the nosharedeletelock and the noshareread lock, or a combination thereof. In order todefine the new locktype property in DAV (and the lock types) thedocument type definitions (DTD) shown in Table 1 may be implemented. Ofcourse these samples could also be written as schemas.

TABLE 1 Sample DTD Definitions For LockTypes: 1 Name: locktypeNamespace: DAV: Purpose: Specifies the access type of a lock. <!ELEMENTlocktype (write | nosharewrite | nosharedelete | noshareread)+> 2Name: write Namespace: DAV: Purpose: Specifies a write lock.Description: The lock conflicts with all updates, including both writesand deletes. It is equivalent to (nosharewrite, nosharedelete). Anexclusive write lock will conflict with shared or exclusive write,nosharewrite, or nosharedelete locks. <!ELEMENT write EMPTY> 3Name: nosharewrite Namespace: DAV: Purpose: Specifies a lock thatconflicts with write operations. Description: Holding this lock preventsothers from adding new properties or updating existing properties of aresource. The lock conflicts with all write operations. This includesadding new properties or resources and updating existing ones. It doesnot conflict with deleting properties or resources. An exclusivenosharewrite lock will conflict with a shared or exclusive write ornosharewrite lock. <!ELEMENT nosharewrite EMPTY> 4 Name: nosharedeleteNamespace: DAV: Purpose: Specifies a lock that conflicts with deleteoperations. Description: Holding this lock prevents others from deletinga resource or its properties. The lock conflicts with all operationsthat delete resources or properties. An exclusive nosharedelete lockwill conflict with a shared or exclusive write or nosharedelete lock.<!ELEMENT nosharewrite EMPTY> 5 Name: noshareread Namespace: DAV:Purpose: Specifies a lock that conflicts with read operations.Description: Holding this lock prevents others from reading a resourceor its properties. Note that the use of this locktype will require readmethods including GET and PROPFIND to use the conditional If format tospecify the opaquelocktoken. The lock conflicts with all readoperations. An exclusive noshareread lock will conflict with a shared orexclusive noshareread lock. <!ELEMENT noshareread EMPTY>

As shown in Table 1, three new values are added to the locktype XMLelement defined in DAV. These values will enable the use of sharedlocking methods for write, read and delete. Additionally, these valueswill enable better support of applications written to other programmingmodels or platforms that use similar sharing methods, such as the Win32®programming model.

In order to create or get one of these lock type values in connectionwith an object, a request is made that includes lock request informationsuch that the lock request is coincident with the access request.Consequently, when a client system is requesting access to an object, orrequesting to create and use an object, the client system includesrequests for the type or types of locks to be created and enforcedduring its use of that data object. The server computer systemdetermines whether to provide the lock type requested. Once a lock typeis granted, the server computer system enforces the lock type againstother access requests.

FIG. 4 is a flow chart of the operational characteristics related toaccessing and locking an object according to aspects of the presentinvention. Prior to the beginning of flow 400 an object, such as object204 and/or 206 shown in FIG. 3, may already exist within a Server SystemResource Store, such as store 202. In such an embodiment, once theobject has been created, then any later attempt to access that objectinitiates the flow 400 shown and described with respect to FIG. 4. In analternative embodiment however, e.g., such as when the DAV protocol isused, the object may not exist prior to flow 400. In such a case, a lockobject may be created in parallel with the creation of a data object, orthe lock object may be created and later associated with the data objectonce the data object is created.

Process 400 generally begins with receive operation 402, wherein thereceive operation 402 relates to the receipt, by the server system ofany read, execution, or update access request related to an object. Theaccess attempt may be performed by a third party application, such asapplication 218 or 220 (FIG. 3) or by the services layer 214, amongothers. The access request incorporates information related to the typeof access that is being requested, i.e., to read, to write, to delete,etc. Additionally, the request information may also include informationas to the type of lock to be created and applied while the object is inuse. For example, the access request may be a write access request,meaning that the client application is requesting access to write to, oredit the resource or object. The request also includes lock informationsuch as read-share lock request, meaning that others may read theresource while the client is writing to the resource. Moreover, therequest information may also include a request for a lock token to bereturned to the client application, as described below.

Following receipt operation 402, determination act 404 determineswhether the access may be allowed. Determining whether or not an accessmay be allowed involves an evaluation of existing lock information forthat resource. That is, the server must determine whether the resourceis locked by another client application program. Determining whether theresource is locked, in an embodiment of the invention, involvesrequesting lock properties from the resource object itself. In such acase, the resource may be associated with a lock object, such as objects208 and 210 (FIG. 3) and the lock objects may be evaluated to determinethe type of lock, if any, presently being enforced for the requestedresource. In other embodiments, the determination relates to anevaluation of a look-up table that is managed by the services layer 214.Yet other embodiments may incorporate other means of providinginformation related to whether an object is locked and, if so, the typeof lock.

If determination act 402 determines that the requested resource may notbe accessed, then access is denied at operation 406 and flow ends at endoperation 408. In such a case, a message may be sent to the requestingclient application for the purposes of informing the client that theaccess was denied and for what reason, e.g., that the object is lockedby another client application. Additionally, the returned message mayalso indicate the type of lock that is presently being enforced for thatobject, in case the client wishes to attempt another type of access.

If determination act 404 determines that the requested resource may beaccessed, flow branches YES to create lock operation 410. Create lockoperation 410 performs the creation and/or association of a lock objector other lock-related data structure with the requested object. The typeof lock object that is created relates to the type requested by theclient application. The lock object generated by operation 410 may thenbe evaluated during other access requests until the lock object isremoved or invalidated.

Following the creation of the lock operation 410, return token operation412 returns a lock token to the client application that requested accessto the object. Return token operation 412 essentially provides theclient application information related to the newly created lock object.Additionally, in an embodiment of the invention, this lock token mayalso include specific, predetermined key information related to the lockobject. The key information may then be used by the client applicationat a later time to gain access to the locked object.

Upon returning the lock token to the application, perform accessoperation 414 performs the requested access, i.e., the access requestedat operation 402. The client application may then perform the type ofaccess, e.g., read, write, execute, delete, etc. on the resource thathas been requested. Following performance of the access, flow 400 endsat end operation 408.

In accordance with other aspects of the present invention, the DAVprotocol is extended to incorporate “advisory locks.” An advisory lockmay or may not be honored by a client application 218 or 220 or theservices layer 214. Instead, the requesting application may inquire asto the existence of an advisory lock and then determine whether to honorthat lock. The advisory status may be combined with any type of lock,such as the nosharewrite, noshareread and nosharedelete lock typesdescribed above.

In one embodiment the implementation of advisory locks relates to addinga new lock enforcement rule, e.g., by creating a “lockenforcementrule”property to the lockinfo XML element defined in DAV. The definitions ofthe lockinfo, lockentry, and activelock XML elements are extended tosupport this new lock property. The DTD definition of lockinfo andactivelock are updated as well. The new DTD definitions are shown inTable 2.

TABLE 2 Sample DTD Definitions To Enable Advisory Locks: 1Name: lockentry Namespace: DAV: Purpose: Defines the types of locks thatcan be used with the resource. <!ELEMENT lockentry (lockscope, locktype,lockenforcementrule?)> 2 Name: lockenforcementrule Namespace: DAV:Purpose: Specifies the whether the lock should prevent conflictingoperations or not. Description: A mandatory enforcement rule will causeconflicting operations to be failed and an advisory enforcement rulewill only fail conflicting LOCK or UPGRADELOCK operations. The defaultvalue is mandatory. <!ELEMENT lockenforcementrule (mandatory |advisory)> 3 Name: mandatory Namespace: DAV: Purpose: Specifies thatoperations that conflict with the lock should be failed. Description:The server should fail any operations that conflict with this lock. Forexample, a PROPPATCH command will be failed if the resource isnosharewrite or write locked and the caller does not own the lock.<!ELEMENT mandatory EMPTY> 4 Name: advisory Namespace: DAV: Purpose:Specifies that only LOCK and UPGRADELOCK operations that conflict withthe lock should be failed. Other operations will be allowed to proceed.Description: The server should only fail LOCK and UPGRADELOCK operationsthat conflict with this lock. For example, a PROPPATCH command will beallowed to proceed if the resource is nosharewrite or write locked andthe caller does not own the lock. However, an attempt to acquire anexclusive nosharedelete lock will fail if it is already held. <!ELEMENTadvisory EMPTY>

FIG. 5 is a flow chart of the operational characteristics related toaccessing an object according to aspects of the invention related to theuse of advisory locks. As described above with respect to FIG. 4, priorto the beginning of flow 500 an object, such as object 204 and/or 206shown in FIG. 3, exist within a Server System Resource Store, such asstore 202. In this particular embodiment of the invention, once anobject has been created, then any attempt to access that objectinitiates the flow 500 shown and described with respect to FIG. 5.

Flow 500 begins with receive operation 502, wherein the receiveoperation 502 relates to the receipt, by the server system of any read,execution, or update access request for an object. The access attemptmay be performed by a third party application, such as application 218or 220 (FIG. 3) or by the services layer 214, or by yet otherclient-type requesting entities. The request itself may includeinformation as to the type of access sought, any lock types to becreated and enforced during the access, a request for a lock token, etc.Additionally, in this particular case, the request may provide anindication whether advisory locks should be recognized, i.e., honored.In an embodiment of the invention, the request may explicitly indicateto not recognize advisory locks, or the request may simply provide noindication as to how advisory locks should be handled. In such a case,no indication relates to a request that advisory locks should not berecognized.

Once the request has been received, determination act 504 determineswhether the requested resource is locked. Thus, determination act 504determines whether the resource is locked by another client applicationprogram by either searching for a lock object associated with theresource, analyzing properties of the resource object itself, or bysearching for lock information in a look-up table type of datastructure. In either situation, the server analyzes any lock informationfor the requested object and determines whether an associated lockconflicts with the type of access requested.

If determination act 504 determines that the type of request does notconflict with any lock objects associated with the requested object,flow 500 branches NO to create lock object operation 506. Create lockobject operation 506 creates a lock object and associates the lockobject with the requested resource. Operation 506 is similar in functionto create lock object operation 410 described above in conjunction withFIG. 4. Following creation of lock object operation 506, return tokenoperation 508 returns a lock token to the client application thatrequested access to the object. Return token operation 508 is similar toreturn lock token operation 412 described above in conjunction with FIG.4.

In alternative embodiments, the request received at operation 502 doesnot request that a new lock be created and in such a case, operations506 and 508 may be omitted. Additionally, in other embodiments, a locktoken is not requested and therefore operation 508 is omitted.

Once it has been determined that no conflicting locks are associatedwith the requested resource, and any requested locks have been created,then perform access operation 510 performs the requested access. Uponperformance of the requested access, flow 500 ends at end operation 512.

If determination act 502 determines there is a lock associated with therequested resource that conflicts with the requested access, then flow500 branches YES to test act 514. Test act 514 tests the lock todetermine whether the lock is an advisory lock or whether the lock ismandatory. Testing whether the object is advisory relates to checkingthe property named lockenforcementrule. If this property is set tomandatory, then flow branches NO to deny access operation 516, whichdenies access to the requested resource and flow 500 ends at operation512.

However, if lockenforcementrule property is set to advisory, then flow500 branches YES to request evaluation act 518. Request evaluation act518 evaluates the request received at operation 502 to determine whetherthe request provides an indication as to whether the advisory lockshould be recognized. That is, in this embodiment, the initial accessrequest incorporates a flag or some other data that indicates thatadvisory locks should be recognized and therefore preventing access tothe requested resource. A request may be from a certain type ofapplication, such as a UNIX application and that, by itself, may providethe indication that advisory locks should be recognized. Still othermeans may be employed to provide the necessary information to the serverindicating whether to honor the advisory lock or to ignore the advisorylock. In an alternative embodiment, the server sends a query to therequesting application to determine whether the advisory lock should behonored.

If request evaluation act 518 determines that the advisory lock shouldbe recognized, then flow branches YES to deny access operation 516. Denyaccess operation 516 effectively denies the access request, and may alsosend a notice informing the client of the nature of the lock and thereason for the denial of access.

On the other hand, if the request evaluation act 518 determines that theadvisory lock should not be recognized, then flow branches NO to createoperation 506. As discussed above, create operation creates a lockobject, if one is requested as long as it does not conflict with theexisting lock. Following creation of the lock object, return lock token508 returns a lock token to the application, and then perform accessoperation 510 performs the requested access.

In an embodiment of the invention, however, the advisory locks arehonored for particular types of requests, even if the request does notspecify that advisory locks should be honored. For example, requests forexclusive locks are denied based on the fact that the object is in useby another client and an exclusive lock may not be given under thosecircumstances. Similarly, requests to upgrade or modify the lock typeeven though an advisory lock is used since the upgrade may beinconsistent with the existing lock scheme.

The above described system and method provides a significant advantageover prior methods of managing resource locks in a distributedenvironment. In particular, the use of shared locks modes and advisorylock types advance the locking schemes and enables compatibility withexisting, non-DAV related applications.

As discussed above, the invention described herein may be implemented asa computer process, a computing system or as an article of manufacturesuch as a computer program product. The computer program product may bea computer storage medium readable by a computer system and encoding acomputer program of instructions for executing a computer process. Thecomputer program product may also be a propagated signal on a carrierreadable by a computing system and encoding a computer program ofinstructions for executing a computer process.

Additionally, although the invention has been described in languagespecific to structural features and/or methodological steps, it is to beunderstood that the invention defined in the appended claims is notnecessarily limited to the specific features or steps described.Therefore, the specific features and steps are disclosed as preferredforms of implementing the claimed invention.

1. A computer storage medium having stored thereon a locked resourceaccessed with a Distributed Authoring and Versioning (DAV) protocolmessage, wherein the DAV protocol is an extension of Hypertext MarkupLanguage (HTTP), and wherein the locked resource comprises: a dataobject to store object data; and a lock object, wherein the lock objectis associated with the data object, and wherein the lock objectcomprises information relating to a type of lock on the associated dataobject, and wherein the lock object further comprises a property that isof a noshare type.
 2. A computer storage medium as defined in claim 1,wherein the property is a noshareread type.
 3. A computer storage mediumas defined in claim 1, wherein the property is a nosharedelete type. 4.A computer storage medium as defined in claim 1, wherein the property isa nosharewrite type.
 5. A computer storage medium as defined in claim 1,wherein the lock object services a lock token request.
 6. A computerstorage medium as defined in claim 1, wherein a services layer processesan access request for the data object.
 7. A method of locking a resourcein a distributed environment communicating in a Distributed Authoringand Versioning (DAV) protocol, wherein the DAV protocol is an extensionof Hypertext Markup Language (HTTP), the method comprising: sending arequest in the DAV protocol to access a resource, wherein the resourcecomprises a data object, and wherein the request originates from anapplication program; processing the request; causing the creation of alock object having a predetermined type, wherein the predetermined typeis one from the group consisting of a nosharewrite, a noshareread, and anosharedelete; receiving a lock token upon the creation of the lockobject; and accessing the resource.
 8. A method as defined in claim 7,wherein the application program is a client application programoperating on a client system.
 9. A method as defined in claim 7, whereinthe application program is part of a server system.
 10. A method asdefined in claim 7, wherein the application program causes the creationof the lock object.
 11. A method as defined in claim 7, wherein aservices layer creates the lock object and associates the lock objectwith the data object.
 12. A method as defined in claim 7, wherein theact of processing the request comprises: determining whether theresource is locked by another application program; and determining thetype of access requested.
 13. A method as defined in claim 7, whereinthe lock is advisory.
 14. A method as defined in claim 7, wherein aplurality of application programs can cause the creation of a lock onthe resource.
 15. A system for creating and managing a lock object in adistributed environment communicating in a Distributed Authoring andVersioning (DAV) protocol, wherein the DAV protocol is an extension ofHypertext Markup Language (HTTP), the computer system comprising: anapplication program, the application program operable to send a requestin the DAV protocol to access a data object; and a services layer, theservices layer operable to determine a type of access requested for thedata object and to determine if the data object is associated with thelock object, wherein the lock object comprises a locktype property. 16.A system as defined in claim 15, wherein the services layer is furtheroperable to: determine whether access may be given for the data objectfor the type of access requested; if access may be given for the type ofaccess requested, returning a lock token; and if access may not be givenfor the type of access requested, denying access.
 17. A system asdefined in claim 15, wherein the locktype property is a nosharewritelock.
 18. A system as defined in claim 15, wherein the locktype propertyis a nosharedelete lock.
 19. A system as defined in claim 15, whereinthe locktype property is a noshareread lock.
 20. A system as defined inclaim 15, wherein the locktype property is an advisory lock.